The present invention generally relates to correction of protocol errors in computer networking software, and more particularly, to an apparatus and methods for correcting a class of protocol errors that is compatible with the protocol suite being used in computer networking software for, e.g., a local area network (LAN).
As packet-based communications networks have been in use for many years, computer networking software has evolved to the point where the networking protocol stacks have become very large and complex. In particular, the networking protocol stack of a computer networking software product that extensively employs the latest distributed object networking techniques can be so large and complex that significant errors and critical omissions in the networking protocol stack are likely to occur. Examples of computer networking software products with large networking protocol stacks are T.120 user application programs for the relatively new telephony-over-LAN (ToL) systems, such as H.323 systems. H.323 and T.120 protocols are discussed herein merely as exemplary networking protocols.
Resolving the issues created by such networking protocol stack errors in modern computer networking software products is increasingly important to the system builder who desires to overcome the problems introduced by the large size of today's networking protocol stacks and by modern distributed networking technologies.
Although a variety of approaches have been conventionally used by system builders to try to resolve the issues related to these networking protocol stack errors, these approaches have drawbacks or are insufficient for modern networking technologies and the increasingly large networking stacks. A first approach has been to evaluate competitive vendors of networking software products and then choose that vendor with the networking software product having the fewest number of problems or bugs related to networking protocol stack errors (also referred to herein as protocol bugs). However, this approach of selecting among vendors may be limited, especially since there may only be a small number of vendors for many of the most leading edge networking protocol stacks. As an example, at present there is one vendor of the complete T.120 stack on the personal computer (PC) platform for ToL systems, with several other vendors offering only restricted access to part of the functionality of the T.120 stack or one derived from it. As another example, products for the H.323 networking protocol stack have only a few more vendors than T.120 since these stacks have become so large and labor intensive to create that very few companies find entering this ToL business an attractive prospect. A second approach, which may be used in addition to the first approach, is to work with a selected vendor to get that vendor to correct such protocol bugs in the networking software product. However, this approach may be problematic since the vendor may not be very responsive in correcting such bugs. Moreover, when there are fewer numbers of vendors, the selected vendors may be less responsive to the system builder customer in part due to the scarcity or lack of alternative vendors that may be used. In a market of few vendors, the selected vendor may not be overly responsive to the system builder customer's demands for error correction since the system builder customer as merely one of many customers has only diluted influence on the selected vendor's actions. In addition, the selected vendor may be less responsive to the system builder customer if the vendor is a competitor in some markets. A third approach, which may be used in addition to the first and/or second approaches, is to simply eliminate those features in the networking software product that may depend on any protocol bugs in the networking software product. The disadvantage of this approach is that eliminating functionality that depends on a broken part of the protocol stack in distributed object networks can severely restrict the features offered to the end user. A fourth approach is for the system builder to implement the networking protocol stack on its own rather than buying a networking software product from a vendor. Although this approach allows the system builder to fix protocol bugs regarded as important in a more timely manner, the system builder would incur high costs in both manpower and time to develop its own networking protocol stack. For example, developing a networking protocol stack such as T.120 or H.323 could take an extended amount of time, incur extremely high development and labor costs, and possibly incur other costs such as maintaining a presence on international standards setting committees.
Therefore, if a protocol stack has defects, system builders have had to and will continue to resort to the above-described conventional approaches which have some disadvantages for modern networking software products with large network protocol stacks. Thus, it is desirable to have alternative and/or supplemental techniques for resolving network protocol stack errors in modern computer networking software products.